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Abstract 

This  work  is  motivated  by  our  informal  observation  that  corporations  re-design  their  products 
and  their  organizations  quite  separately.  We  find,  however,  that  the  relationship  of  product 
architecture  to  organizational  design  is  an  intricate  one.  This  study  provides  a  rudimentary  basis 
for  understanding  the  linkages  between  product  architecture  and  organizational  design,  which 
may  allow  managers  to  implement  the  appropnate  organizational  or  architectural  structures.  In 
addition,  a  thorough  understanding  of  the  reliance  that  product  architecture  has  upon 
organizational  design  and  vice  versa  can  aid  managers  in  creating  an  environment  in  which 
product  architecture  can  exploit  the  advantages  of  the  current  organizational  design  and  in  which 
the  organrzational  design  can  enhance  the  effuiency  of  the  personnel  interactions  ref^'iired  ^o 
implement  a  product's  architecture.  We  discuss  several  observations  about  the  dimensions  by 
which  these  attributes  are  coupled. 
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I.  Introduction 

This  paper  explores  the  interdependence  between  two  key  decision  areas  in  the  development  of 
new  products:  product  architecture  and  organizational  design.  We  conducted  a  field  study  of 
audio  system  development  in  a  major  American  automotive  firm.  This  firm  competes  in  global 
markets  and  utilizes  new  technologies  which  give  rise  to  several  p)ossible  product  architectures 
and  organizational  structures.  By  separating  these  decisions  for  our  discussion,  we  are  able  to 
explore  some  of  the  fundamental  issues  which  couple  them.  Our  results  suggest  several  ways  in 
which  decisions  and  plans  for  product  architecture  and  organizational  design  must  be  integrated. 

In  order  to  explore  the  coupling  between  these  two  issues,  we  focused  our  study  along  the 
following  dimensions:  product  and  problem  decompositions,  integration  mechanisms, 
communication  patterns,  supplier  relationships,  and  reporting  structures.  We  define  product  and 
problem  decomposition  to  be  the  practice  of  splitting  a  complex  engineering  challenge  into 
several  simpler  ones,  while  integration  is  the  challenge  of  merging  solutions  to  these  separate 
problems  into  an  overall  system.  Communication  patterns  (i.e.  how  information  might  flow) 
depend  on  the  type  and  structure  of  the  project  team  [Barczak  and  Wilemon  1991].  Supplier 
relationships  can  take  a  myriad  of  forms.  Therefore,  we  were  particularly  interested  in 
investigating  the  characteristics  of  these  alliances  which  might  have  influenced  product 
architectures.  Reporting  structures  we  examined  were  those  which  affected  or  were  affected  by 
the  outcomes  of  the  product  architecture/organizational  design  coupling. 


Figure  1.  Problem  Decomposition  and  Organizational  Assignment. 
The  organization  must  decompose  the  complex  problem  and 
all(x;ate  tasks  to  the  product  de\clopment  team  (solid  arrows). 
Additionally,  information  must  be  ccx)rdinated  across  individuals, 
teams,  and  suppliers  (dashed  arrows). 

Past  research  in  product  development  has  shown  that  a  company's  capability  to  conceive  and 

design  a  variety  of  superior  prcxiucts  and  bring  them  to  market  faster  than  its  competitors  can  be 

a  source  of  significant  competitive  advantage  [Wheelwright  and  Clark  1992J.  Wheelwright  and 

Clark  emphasize  the  imptxtance  of  learning  in  the  organiziition.  Companies  that  follow  a  path  of 

continuous  improvement  in  product  and  process  development  will  more  consistently  "design  it 

right  the  first  time"  and  yield  a  head  start  in  getting  their  products  to  market.  An  understanding 

of  the  key  relationships  in  product  planning  can  facilitate  "design fing]  it  right  the  first  time." 

Prior  research  by  Clark  and  Fujimoto  [1991]  explores  the  impact  of  strategy,  organization,  and 

management  upon  product  development.  They  claim  that  management  direction  and  the 

development  organization  both  play  critical  roles  iii  providing  the  integrated  effort  and 

leadership  needed  to  successfully  execute  a  product's  architectural  plan  and  to  move  that  prtxluct 

efficiently  and  quickly  to  market.  Rosenthal  [1991J  suggests  that,  in  order  to  be  successful,  a 

firm  must  implement  a  managerial  view  of  the  design  and  development  process  that  attempts  to 

help  catch  design  flaws  early,  correct  mistakes,  and  avoid  long  development  delays.  Henderson 

and  Clark  [1990]  indicate  that  "architectural  innovation  has  the  pcHential  to  offer  firms  the 

opportunity  to  gain  significant  advantage,"  in  the  context  of  understanding  that  a  well-entrenched 

organization's  problem  solving  culture  can  be  a  hindrance  to  architectural  innovation.  Finally, 


Clark  [1987]  indicates  that  a  corporation's  problem  solving  structure  mirrors  the  technical  and 
conceptual  structure  of  its  product(s).  Innovative  changes  in  the  product  can  expose 
discontinuities  in  organizational  knowledge,  information  flows,  and  procedures.  Ultimately,  the 
nature  of  these  breaks  can  determine  the  style  of  competitive  response  [Clark  1987]. 

This  research  connects  architectural  choices  and  organizational  choices.  It  expands  on  our 
previous  research  projects  which  have  explored  system  integration  in  complex  development 
environments.  McCord  and  Eppinger  [1993]  highlight  the  importance  of  determining  the  needs 
for  integration  and  coordination  by  studying  the  underlying  technical  structure  of  a  project. 
Pimmler  and  Eppinger  [1994]  show  that  an  understanding  of  the  "system  engineering"  needs, 
which  arise  because  of  complex  interactions  between  components  of  a  design,  is  useful  to  define 
a  product's  architecture  and  to  organize  development  teams.  Finally,  Morelli,  Eppinger,  and 
Gulati  [1995]  propose  that  for  the  management  of  product  development  projects,  certain  aspects 
of  organizational  design  can  be  planned  by  anticipating  the  technical  communication  linkages 
required  for  project  execution. 

In  a  complex  product,  the  co-dependencies  between  architectural  and  organizational  choices  can 
be  important  considerations  when  decomposing  a  problem.  Alexander  [1964]  states  that  there  is 
an  important  underiying  structural  correspondence  between  the  pattern  of  a  problem  and  the 
process  of  designing  the  problem's  solution    In  our  case,  it  is  feasible  that  the  architectural  or 
organizational  decompositions  depended  on  the  numbers  and  distributions  of  their  potential 
intermediate  stable  forms  '.  That  is,  the  direction  in  which  the  organization  or  architecture  might 
evolve  can  be  significantly  influenced  by  it's  prior  form.  Complex  systems  will  evolve  from 
simple  systems  much  more  rapidly  if  there  are  stable  intermediate  forms  than  if  there  are  not. 
Furthermore,  the  components  of  a  technological  system  (such  as  a  complex  organization)  will 
interact.  Therefore,  their  characteristics  will  derive  from  the  system  [Bijker  1987].  Bijker, 


Intermediate  forms  refers  to  prior  architectural  or  organizational  structures. 


Hughes,  and  Pinch  1 1987|  give  ihe  example  of  the  managcmcnl  siruclurc  of  an  cleclric  light  and 
pcnver  ulilily  depending  on  ihc  character  of  the  functioning  hardware  or  artifacts  in  the  system. 
They  also  states  that  the  management  structure  reflects  the  particular  economic  mix  of  artifacts  in 
the  system,  and  the  layout  of  the  artifact  mix  is  analogous  to  the  management  structure.  Simon 
[1990]  argues  that  in  nearly  decomposable  systems  (such  as  these)  the  shorl-run  behavior  of  each 
of  the  component  subsystems  is  approximately  independent  of  the  short-run  behavior  of  the  other 
components.  In  the  long  run,  the  behavior  of  any  one  of  the  components  depends  only  in  an 
aggregate  way  on  the  behavior  of  the  other  components  [Simon  1990J.  In  light  of  the  fact  that 
complex  problems  involve  communication  among  many  people,  von  Hippel  [1990]  proposes  that 
firms  specify  tasks  in  order  to  reduce  the  problem-solving  interdependence  among  them  by 
predicting  w  hich  tasks  are  likely  to  be  important  new  information  sources  and  which  tasks  affect 
each  other. 

Product  Architecture 

We  define  product  architecture  to  be  the  set  of  technical  decisions  (the  plan)  for  the  layout  of  the 
product,  its  modules,  and  for  the  interactions  between  the  modules.  Product  architecture  is  the 
scheme  by  which  the  function  of  a  product  is  allocated  to  physical  components.  It  can  be  a  key 
driver  of  the  performance  of  the  manufacturing  firm  and  relates  to  product  change,  product 
variety,  component  standardization,  product  performance,  and  prcxluct  development  management 
[Ulnch  1995].  In  some  companies,  the  product  architectures  of  flagship  products  might  even 
guide  decision  prcx:esses.  At  Sony,  design  is  done  very  differently  depending  on  the  product. 
For  the  Walkman,  generational  changes  are  led  by  engineering,  with  heavy  involvement  from  top 
management.  In  other  products,  marketing  and  sales  lead  certain  classes  of  changes.  In  products 
that  do  not  fit  in  either  of  the  above  two  categories,  the  industrial  design  organization  plays  a 
heavy  role  [Sanderson  1995]. 


The  physical  elements  of  a  product  are  the  parts,  components,  and  subassemblies  that  ultimately 
implement  the  product's  functions.  The  chunks  are  the  collections  of  these  elements  and  so  may 
implement  one  or  a  few  functional  elements  in  their  entirety  [Ulrich  and  Eppinger  1995].  A 
modular  architecture  is  one  in  which  chunks  implement  one  or  a  few  functional  elements  in  their 
entirety,  and  where  the  interactions  between  the  chunks  are  fundamental  to  the  primary  functions 
of  the  product.  An  example  of  a  modular  architecture  is  a  car  radio  which  is  utilized  in  several 
different  audio  systems  across  vehicle  lines  and  is  a  stand-alone  product.  An  integral 
architecture  is  the  opposite  of  a  modular  architecture.  It  is  one  in  which  a  single  chunk 
implements  many  of  the  functional  elements,  and  where  the  interactions  between  the  chunks  are 
not  well-defined  and  may  be  incidental  to  the  function  of  the  product.  An  example  of  an  integral 
architecture  is  the  integrated  control  panel  developed  for  the  1996  Ford  Taurus  audio  and  climate 
control  systems. 


Figure  2.  Ford's  Integrated  Control  Panel 


Orf^cinizdliondl  Design 

Organizational  design  is  the  decision  process  that  brings  about  a  coherence  between  the  goals 
and  purposes  for  which  the  organi/iilion  exists,  the  patterns  of  division  ol  labor  and  interunit 
coordination  and  the  people  u  ho  w  ill  do  the  work  [Galbraith  1977].  We  focus  our  attention  on 
the  creation  of  formal  managerial  processes  and  communication  channels  that  facilitate  the 
organization's  decision  process.  One  important  dimension  of  organizational  design  is  the  type  of 
structure  that  gives  rise  to  its  capabilities  and  coordination  abilities.  A  pure  functional 
organization  encourages  long-term  technical  specialization.  However,  physical  and 
organizational  distance  between  sub-functions  increases.  A  pure  project  organization  focuses  an 
organization's  energies  major  development  projects  and  encourages  cross-functional 
communication.  However,  by  doing  this,  it  may  sacrifice  some  functional  expertise 
[Wheelwright  and  Clark  1992]. 

A  matrix  organization  integrates  the  specialized  resources  of  the  organizations  without 
organizing  around  a  self-contained  product  or  project  [Galbraith  1977].  Although  a  matrix 
organization  solves  many  of  the  problems  of  pure  functional  and  pure  project  organizations,  it  is 
important  to  recognize  that  it  has  other  drawbacks  which  are  beyond  the  scope  of  this  paper  (e.g. 
problems  caused  by  p)oor  relations  between  units)  [Galbraith  1994]. 

Other  organizational  design  mechanisms  include  the  creation  of  slack  resources  (i.e.  adding 
additional  resources  and  reducing  each  individual  group's  required  level  of  performance), 
creating  .self-contained  tasks  (i.e.  assure  that  each  group  has  all  the  resources  it  needs  to  perform 
its  task),  investing  in  vertical  information  systems  (i.e.  invest  in  mechanisms  which  allow  the 
organization  to  process  information  acquired  dunng  task  performance  without  overkxiding  the 
hierarchical  communication  channels),  or  creating  lateral  relations  (i.e.  selectively  employ  lateral 
decision  processes  which  cut  across  lines  of  authority)  [Galbraith  1973]. 


Coupling  Architecture  to  Organization 

While  other  research  has  analyzed  the  dimensions  of  decomposition  of  organizations  and  product 
architectures  independently  [Sanderson  1995,  Uzumeri  1995,  Meyer  1993],  this  paper  highlights 
the  ways  in  which  organizational  competencies  and  frameworks  are  coupled  to  architectural 
interactions  and  their  function  in  the  organizational  structure.  We  draw  the  conclusion  that  this 
distinct  relationship  merits  special  consideration  in  managerial  decision  making.  A  thorough 
understanding  of  the  reliance  that  product  architecture  has  upon  organizational  design  and  vice 
versa  can  aid  managers  in  creating  a  beneficial  environment  in  which  product  architecture  can 
exploit  the  advantages  of  the  current  organizational  design  and  in  which  the  organizational 
design  can  enhance  the  efficiency  of  the  personnel  interactions  required  to  implement  a  product's 
architecture.  Additionally,  organizational  design  can  assist  the  execution  of  a  product's 
technology  by  facilitating  the  integration  of  various  disciplines,  technologies,  components,  and 
systems  into  a  product. 

The  next  section  of  this  paper  outlines  our  research  methodology  and  introduces  the  audio- 
system  design  focus  of  our  field  work.  Then  we  present  examples  of  architecture  affecting 
organizational  design  and  organizational  design  affecting  architecture,  and  discuss  the  coupling 
of  these  decisions.  We  conclude  with  a  summary  of  the  implications  for  practitioners  and 
directions  for  future  research. 

II.  Audio  System  Case  Studies 

The  data  for  this  case  study  come  from  interviews  and  observations  of  audio  system  development 
teams  in  two  very  different  organizations  (one  American  and  one  European)  in  a  major  US 
automotive  manufacturing  firm.  Although  under  the  same  parent  company,  the  two  sites  are 
different  in  many  ways,  including  culture,  language,  work  habits,  vehicle  programs,  management 
style,  technical  capabilities,  supplier  relationships,  and  scope  of  technical  responsibility.  We 
interviewed  personnel  in  engineering,  managerial,  and  business  functions  from  global 


8 


developmcnl  teams  on  26  dilTcrcnl  car  lines  and  63  audio  systems.  Thjs  particular  company 
designs  and  manufactures  about  3(X)  different  radios.  The  inters  iew  s  were  conducted  over  a  five 
month  period  in  1995.  Our  study  concentrated  largely  on  factory  installed  automotive  audio 
systems.  Finally,  we  extracted  the  examples  from  the  case  studies  and  re-framed  them  into  more 
general  issues  for  our  presentation  here. 

An  audio  system  consists  of  all  the  components  in  a  vehicle  which  aid  in  providing  audible 
information.  These  components  include,  but  are  not  limited  to  the  radio,  amplifier,  speakers, 
wiring  harness,  and  cellular  telephone. 
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Figure  3.    Audio  System  A  n-hitcci'ire. 
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At  first  glance,  an  audio  system  may  appear  to  be  a  very  simple  group  of  components.  In  reality, 
however,  it  is  quite  complicated.  An  audio  system  can  involve  anywhere  from  4(X)  to  600 
components,  six  to  ten  design  engineers,  and  three  to  five  outside  suppliers.  It  can  also  take  three 
years  to  fully  develop.  The  company  we  studied  develops  ten  to  twenty  audio  systems  at  one 
time.  Outside  suppliers  are  often  in\ol\cd  in  \arious  functions  including:  integrated  circuit 
design,  be/el  design,  lamps  for  displays,  and  telephone  systems. 


Some  of  the  complexity  in  an  audio  system  arises  from  the  technical  interactions  and  coupling 
effects  from  nesting.  Nesting  refers  to  the  idea  that  components  within  a  larger  system  are  self- 
contained,  such  as  the  audio  system  within  a  vehicle  [Christensen  and  Rosenbloom  1995].  Both 
modular  and  integral  architectures  can  be  arranged  in  a  nested  fashion.  In  a  nested  hierarchy, 
each  component  can  also  be  viewed  as  a  system  which  comprises  sub-components  whose 
relationships  to  each  other  are  also  defined  by  a  product  architecture.  Similarly,  the  product  may 
also  be  viewed  as  a  component  within  a  larger  system,  relating  to  other  components  within  a 
defined  architecture.  Simply,  products  which  at  one  level  can  be  viewed  as  complex  architected 
systems  act  as  components  in  systems  at  a  higher  level  [Christensen  and  Rosenbloom  1995]. 
Subsystems  are  defined  as  systems-of-use  within  a  nested  hierarchy  of  product  architectures. 
Figure  4  illustrates  a  nested  hierarchy  of  product  architectures  from  vehicle  audio  systems  to 
entire  vehicle  lines. 

At  the  highest  level,  the  architecture  of  a  vehicle  platform  is  comprised  of  all  of  the  different 
vehicle  lines  that  this  particular  company  makes.  At  the  vehicle  platform  level,  pricing  is 
determined,  manufacturing  issues  are  dealt  with,  modular  components  are  specified,  and  the 
service  and  repair  requirements  are  laid  out.  The  next  level  down,  the  architecture  of  a  vehicle 
line  is  where  liaisons  can  be  created  with  marketing  and  sales,  ergonomics  are  taken  into 
consideration,  and  noise,  vibration,  and  harshness  issues  are  often  uncovered.  At  the  third  level, 
the  audio  subsystem  level,  or  any  other  electronic  subsystem  for  that  matter,  the  audio-specific 
customer  requirements  are  uncovered.  The  interface  sfjecifications  and  requirements  and  the 
subsystem  design  specifications  are  delineated.  Lastly,  the  architecture  of  the  radio,  in  turn,  can 
itself  be  analyzed  as  a  system  composed  of  integrated  circuits,  speakers,  and  fascia  design,  for 
example. 
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Figure  4.  A  nested  hierarchy  of  prtxluct  architectures. 

The  interactions  along  with  the  nesting  of  the  audio  system  in  the  automobile  force  a  coupling 
between  the  audio  system  and  the  vehicle.  By  making  design  decisions  of  one  or  the  other 
mdependently,  a  firm  would  sub-optimize  pieces  of  the  entire  automobile. 

III.  Discussion  of  Findings 

In  this  section,  we  will  present  our  findings  by  first  delineating  the  manner  in  which  and  to  what 
extent  architectural  choices  are  coupled  to  the  established  organizational  capabilities  and 
structures.  Next,  we  investigate  the  nature  of  the  cases  in  which  organizational  design  drove 
architectural  decisions. 

A.  Architecture  choices  dictate  organizational  design  choices. 

Developing  audio  systems  for  automobiles  is  a  surprisingly  complex  task.  Not  only  is  the 
architectural  layout  of  a  single  audio  system  extremely  complicated,  but  the  interactions  between 
a  vehicle  and  its  audio  system  may  involve  large  numbers  of  people  and  physical  parts. 
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Decomposition  determines  team  assignments. 

Products  that  are  decomposed  into  architectural  chunks  encourage  the  assignment  of  a  team  to 
each  chunk.  Products  are  usually  decomposed  until  a  team,  individual,  or  supplier  can  be 
assigned  responsibility  for  each  chunk  [Rechtin  1991].  Traditionally  the  groups  of  functional 
elements  in  a  product  have  had  a  functional  team  assigned  to  them.  An  example  of  an  effective 
chunk-to-team  mapping  is  the  assignment  of  automotive  systems  to  departments/teams  such  as  a 
climate  control  systems  or  audio  systems.  For  static  modular  architectures  in  which  the 
interfaces  are  very  well  understood,  this  approach  makes  sense.  However,  when  the  architecture 
changes  or  if  the  interface  parameters  are  not  well  defined,  this  approach  becomes  less 
appropriate  as  it  would  require  the  organization  to  change.  A  change  in  the  organization  would 
probably  be  very  costly  for  just  one  architectural  generation. 

In  other  design  domains  (e.g.  software),  complex  systems  are  broken  into  smaller,  more 
manageable  tasks.  The  complex  details  of  each  of  the  smaller  sub-systems  are  below  the 
abstraction  barrier.  Often  there  is  an  agreement  (or  contract)  to  specify  the  details  of  the 
interfaces  and  parameters  passed  between  the  complex  system  and  each  of  the  sub-systems. 
Effectively,  at  each  level,  the  architecture  is  the  plan  of  all  these  abstractions  and  contracts 
[Moses  1995]  and  teams  are  assigned  to  the  subsystems.  See  Figure  5. 
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Figure  5.  Problem  Decomposition  and  Abstraction 

The  organization  in  our  study  traditionally  has  engineered  strictly  modular  architectures.  So 
people  have  been  grouped  not  according  to  their  technical  specialties,  but  instead  according  to 
the  physical  modules  of  the  product.  Since  today's  audio  system  architectures  are  becoming 
more  integrated,  the  organization  has  adapted  to  accommodate  cross-module  team  structures. 

Incidental  interactions  catalyze  the  formation  of  problem  solving  teams. 

Often  incidental  interactions  occur  at  the  intersection  of  the  decomposed  elements.  In  our  study, 
coupling  problems  were  more  difficult  to  anticipate  in  the  more  novel  technologies.  These 
coupling  issues  give  rise  to  integration  problems  and  cause  the  creation  of  ad  hoc  system 
integration  teams  to  handle  these  issues.  A  solid  analysis  of  where  interactions  can  facilitate  the 
clustering  of  the  high  frequency  interactions  within  subsystems  can  minimize  the  interactions 
across  difficult  barriers  [McCord  and  Eppinger  1993].  Furthermore,  pre-development  planning 
and  product  integrity  enhance  the  performance  of  prtxluct  development  teams  (and  also  minimize 
unplanned  incidental  interactions),  especially  if  the  organiziition  is  very  system  focused,  since 
lead  time  and  prcxluctivity  become  much  more  predictable  (Brown  and  Eisenhardt  1995]. 
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In  our  case  study,  the  formation  of  ad  hoc  teams  on  a  small  scale  was  not  uncommon.  Though 
we  did  find  that  ad  hoc  teams  had  not  been  planned  in  advance  during  the  product  development 
planning  process.  This  lack  of  anticipation  caused  the  program  delays  and  extra  costs.  In  one 
instance,  serious  system  problems  had  not  been  discovered  until  the  entire  audio  system  had  been 
integrated  in  the  vehicle  during  the  prototyping  process.  Due  to  the  urgency  in  correcting  these 
issues  (i.e.  the  vehicle  could  not  be  sold  with  a  malfunctioning  audio  system  and  a  major  delay  in 
the  manufacturing  of  the  vehicle  can  be  extremely  costly),  a  formal  troubleshooting  team  was 
established. 

Architecture  determines  communication  patterns. 

The  layout  of  the  product  architecture's  fundamental  and  incidental  interactions  implies  a 
specific  pattern  of  organizational  communication.  If  there  exist  barriers  to  the  execution  of  this 
pattern,  these  barriers  can  catalyze  delays  in  the  product  development  cycle.  This  issue  becomes 
particularly  relevant  to  co-located  teams,  especially  if  only  a  subset  of  the  larger  development 
team  is  being  co-located.  Additionally,  knowledge  of  specific  types  and  patterns  of 
communication  and  the  ability  to  predict  communications  may  allow  managers  to  implement 
appropriate  organizational  structures  based  on  a  project's  task  structure  [Morelli,  Eppinger,  and 
Gulati  1995]. 

On  the  other  hand,  when  one  can  identify  that  two  people  or  two  groups  need  to  share 
information,  it  is  important  to  assure  that  the  correct  information  exchange  takes  place. 
Sometimes,  an  informal  method  such  as  co-location  by  itself  is  not  sufficient.  For  example,  it  is 
important  not  to  make  the  assumption  that  two  engineers  with  desks  in  close  proximity  will 
communicate  the  necessary  information  to  each  other.  Additionally,  we  know  from  Allen's 
communication  vs.  distance  curve  [Allen  1977],  that  it  is  unlikely  that  engineers  will 
communicate  with  other  engineers  in  their  department  if  they  are  located  several  floors  apart. 
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Furthermore,  the  availability,  transfer,  and  use  of  information  are  all  distinct  concepts.  Co- 
location  increases  the  availabiliiy  ol  the  information,  while  transfer  implies  that  the  information 
is  appropriately  disseminated.    Use  implies  that  the  actual  information  is  utilized.  Co-location 
does  not  necessarily  ensure  that  the  correct  information  will  be  transferred  and  used.  In 
particular,  in  novel  situations,  where  it  is  imperative  that  technical  information  be  transmitted  to 
a  group  relati\ely  unfamiliar  with  the  new  requirements,  firms  might  consider  utilizing  multiple 
information  channels  or  gathering  mcthcxls  in  order  to  insure  transfer  of  the  correct  information 
and  effective  utilization. 

Architecture  determines  the  feasibility  of  co-location. 

If  a  system  is  simple  enough,  the  need  for  high-frequency  interactions  can  be  fulfilled  by 
effectively  co-Icx;ating  the  entire  team.  This  approach  is  valid  and  successful  for  small  projects 
and  teams.  When  the  system  is  complex,  the  same  rules  do  not  apply.  If  the  team  is  large,  the 
reasons  for  co-location  are  no  longer  valid.  Subsystem  dc\  elopers  do  not  need  to  interface 
directly  \\  ith  all  of  the  vehicle  developers  at  all  times.  For  example,  an  audio  system  team  may 
need  to  work  more  directly  with  the  instrument  panel  design  team  during  some  part  of  the 
product  development  cycle;  during  other  parts  of  the  process  the  audio  system  design  team  may 
need  to  interface  with  the  wiring  harness  or  cliirate  control  design  team.  Often,  there  exist 
interactions  which  require  technical  expertise  for  a  short  time  during  the  product  development 
cycle. 

Another  way  to  deal  with  these  complexities  is  by  temporarily  co-locating  one  or  two  key 
engineers  from  the  subsystem  development  team  on  the  vehicle  engineering  team.  This  approach 
might  be  a  feasible  solution  if  only  one  vehicle  team  existed.  However,  in  reality  each  of  the 
many  vehicle  teams  needs  the  expertise  of  a  subsystems  engineer.  In  addition,  the  subsystems 
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department  itself  may  have  its  own  needs  and  be  unwilling  to  part  with  its  engineer(s)  for  an 
extended  period  of  time. 

Given  that  multiple  types  of  integration  exist  (within  product  development  teams,  within  system 
teams  which  are  made  up  of  several  product  development  teams,  and  between  external  teams  and 
product  development  teams),  we  recognize  that  each  integration  is  most  difficult  at  the  larger 
subsystem  level  [McCord  and  Eppinger  1993].  Additionally,  past  research  has  shown  that 
decomposition  becomes  easier  at  the  internal  team  level.  At  low  levels,  integration  is  easy 
because  interactions  occur  in  high  frequencies  over  a  small  cross-functional  team.  At  higher 
levels,  interactions  become  more  occasional  and  less  frequent  as  the  team  gets  bigger. 


Integration  is  easy 
in  a  sma  1  team. 


As  interactions  become 
more  incidental  and  less 
frequent,  integration 
becomes  more  difficult. 


Figure  6.  Interactions  in  an  organization 

Lastly,  a  well  understood  interface  between  architectural  chunks  minimizes  the  need  for  ad  hoc 
communications.  If  the  architecture  can  be  pre-planned  and  all  the  interfaces  can  be  pre- 
specified,  co-location  may  not  be  necessary.  Furthermore,  if  complexity  is  accurately  defined, 
tradeoffs  between  complexity,  quality,  and  product  differentiation  can  be  thoroughly  considered. 
In  our  study,  one  team  dedicated  to  reducing  complexity  championed  the  complexity  issue 
without  due  regard  to  other  factors,  causing  many  decisions  to  be  re-examined  and  resulting  in 
delays  in  the  product  development  cycle. 
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B.  The  established  organizational  capabilities  and  structures  dictate  architectural  choices. 

The  organi/ations  that  manufacture  complex  products  such  as  automobiles  exhibit  complexity  in 
many  facets.  Each  division,  each  department,  each  prcxiuct  development  team  consists  of  many 
different  internal  and  external  networks.  Each  of  these  networks  in  turn  helps  to  define  the 
organizntion.  The  capabilities  and  structures  of  that  organization  then  influence  architectural 
design. 

Sialic  organizations  give  rise  to  static  architectures. 

Results  from  our  study  validated  our  prior  observations  that  fixed  organizational  structures 
generate  products  whose  architectures  remain  fairly  ngid.  We  believe  that  this  generalization 
may  hold  across  some  of  the  major  organization  types  (i.e.  pure  product,  pure  functional  or 
matrix),  however  this  hypothesis  remains  to  be  tested  in  a  future  study.  The  architecture  is  often 
a  reflection  of  the  organization.  If  the  organizational  structure  is  static,  the  architecture  is  likely 
to  be  the  same  over  many  product  generations.  Integrating  and  changing  the  architecture  also 
becomes  difficult.  The  longer  this  cycle  remains  to  be  true,  the  stronger  a  prediction  it  becomes. 

Gi\  en  this  premise,  one  might  suppose  splitting  into  project  organizations,  for  example,  would 
facilitate  having  each  product  architecture  slightly  different  from  the  others,  because  each 
organization  is  a  project  team  (i.e.  either  a  matrix  or  a  hybnd  that  cuts  across  all  the  traditional 
functions,  but  does  not  necessarily  utilize  cross-functional  expertise).  It  appears  that  the  project 
organization  might  be  more  adaptable  to  new  architectures,  because  each  project  team  is  so 
separate.  Innovations  in  one  architecture  may  be  difficult  to  implement  in  the  other  project  team. 
In  fact,  each  particular  organization  may  be  static  and  therefore  produce  a  static  architecture. 

Additionally,  pure  project  organizations  lend  to  produce  architectures  reflectiN  e  of  that  particular 
organization  rather  than  that  of  the  company  as  a  whole.  The  products  may  also  require 
engineering  efforts  that  are  duplicated  in  other  segments  of  the  corporation,  hence  becoming 
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more  costly  than  necessary  [Galbraith  1973].  Pure  functional  organizations  might  be  more 
dynamic  than  pure  product  organizations  (because  the  product  organizations  are  pooled 
together),  but  they  are  more  likely  to  lose  sight  of  the  goals  of  each  individual  product's 
architecture.  Matrix  organizations  can  solve  some  of  these  problems,  but  they  have  other 
problems  which  are  beyond  the  scope  of  this  research.  When  considering  organizational  designs, 
it  is  important  to  recognize  that  there  is  no  one  best  way  to  organize  and  not  all  the  ways  to 
organize  are  equally  effective  [Galbraith  1977]. 

Organizational  skills  and  capabilities  affect  architecture. 

An  organization  with  specific  skills  sometimes  chooses  its  architecture  such  that  the  impact  of 
those  skills  are  maximized  in  order  to  gain  a  competitive  advantage.  As  Meyer  and  Utterback 
[1993]  have  shown,  product  families  can  be  a  result  of  the  underlying  core  capabilities  of  the 
organization.  Furthermore,  the  cross-functional  skills  of  a  successful  product  development 
organization  and  effective  synergies  with  the  firm's  existing  competencies  can  lead  to  a  product 
advantage  [Brown  and  Eisenhardt  1995]. 

For  some  corporations,  this  method  has  proven  to  be  quite  effective.  For  example,  in  1933 
Toyota's  founder,  Toyoda  Kiichiroo  announced,  "We  shall  learn  production  techniques  from  the 
American  method  of  mass  production.  But  we  will  not  copy  it  as  it  is.  We  shall  use  our  own 
research  and  creativity  to  develop  a  production  method  that  suits  our  own  country's  situation" 
[Ohno  1988].  During  the  1970s  and  1980s,  Toyota  challenged  GM  for  the  title  of  the  world's 
largest  automobile  manufacturer  [Pine  1993]. 

Supplier  relationships  can  affect  architecture. 

Managing  supplier-customer  relationships  is  a  very  complex  task.  Ignoring  the 
interdependencies  in  this  partnership  can  have  dire  consequences  later  in  the  product 
development  cycle  [Kim  1993].  Some  of  the  major  ways  in  which  automotive  suppliers  have 
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been  organized  in  ihc  past  have  been  either  to  be  dedicated  supphers  or  if  they  weren't  dedicated 
suppliers,  long  term  relationships  had  been  established  such  that  both  the  supplier  and  the 
manufacturer  underslcxxl  one  another's  mode  of  operation  and  the  manufacturer  had  the  ability 
then  to  anticipate  and  know  w  hich  supplier  to  call  when  the  time  for  early  supplier  involvement 
came  around.  The  advantage  of  such  a  relationship  is  that  purchasing  did  not  have  to  be 
involved  to  qualify  a  new  supplier  and  time  was  saved  during  the  prcxiuct  development  cycle. 

In  our  study,  the  suppliers  were  not  dedicated,  and  we  noticed  that  if  the  suppliers  did  not  have 
the  same  incentives  as  the  prcxiuct  development  teams,  the  quality  and  the  timeliness  of  the 
interdependent  tasks  was  poor.  We  surmise  that  this  may  be  the  case  because  each  of  the 
subteams  of  the  larger  prcxiuct  development  team  has  its  own  organizational  allegiances  or 
personal  agendas  that  precede  their  commitments  to  the  goals  of  the  project.  Furthermore,  these 
allegiances  may  exacerbate  the  problem  of  sub-optimizing  the  smaller  systems  by  creating 
disincentives  to  globally  optimize.  In  the  case  oi  the  suppliers,  they  wanted  to  maximize  their 
profits. 

Sc^metimes,  this  can  result  in  higher  than  necessary  cnerall  \  chicle  costs  if  the  supplier  develops 
an  architecture  that  reaches  beyond  the  specifications  of  the  original  architecture.  An 
understanding  of  the  supplier's  agenda  can  allow  one  to  position  the  product  such  that  the 
supplier  can  cither  get  more  sales  volume  or  utilize  t'leir  eniiinecring  expertise  in  other  profit 
making  \  enturcs.  Lack  of  commitment  and/or  lack  of  goal  alignment  from  all  segments  of  the 
prcxiuct  development  team  can  be  due  to  a  desire  to  appease  upper  management  outside  the 
subsystem  group  at  the  expense  of  a  prcxluct's  design,  a  desire  for  a  vehicle  program  manager  to 
make  a  radical  change  late  in  the  subsystem  development  cycle,  cultural  differences  in 
geographically  disparate  departments,  different  compensation  systems  in  different  countries,  or 
different  employee  motivators  in  different  cultures. 
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Organizational  design  of  a  globally  distributed  team  affects  architecture. 
Sometimes  there  are  compelling  reasons  to  globally  distribute  a  multi-national  product 
organization  with  global  sales  (e.g.  keeping  in  touch  with  customers,  being  close  to 
manufacturing  facilities,  etc.).  Given  this  global  distribution,  it  would  be  ideal  to  cluster  the 
architecture  such  that  the  high-  frequency  interactions  take  place  within  each  site  and  low- 
frequency  interactions  can  occur  across  sites.  We  have  yet  to  demonstrate  that  virtual  co- 
location  (using  collaborative  technologies  such  as  video  conferencing,  electronic  mail, 
distributed  databases,  Internet,  CAE,  etc.)  is  comparable  to  physical  co-location. 

For  example,  we  observed  that  a  globally  distributed  organizational  structure  can  cause  difficulty 
in  scheduling  video-conference  or  tele-conference  meetings  due  to  very  little  overlap  in  the 
workday  and  difficulty  in  coordinating  team  projects  when  the  team  itself  is  geographically 
separated.  Co-location  is  not  always  the  correct  answer  to  these  problems.  Good  reasons  for  co- 
location  in  a  large  team  include  situations  where  there  is  a  lot  of  high-frequency  communication, 
situations  where  interface  specifications  are  not  fully  specified,  or  situations  where 
communication  needs  are  unpredictable. 
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Figure  7.  A  well  specified  interface  between  Teams  A  and  B 
allows  for  less  formal  co-location  methods.  However,  co-locating 
Teams  C  and  D  would  facilitate  the  high-frequency  interactions. 


Virtual  co-kx;ation  can  ea.se  the  problem,  but  not  alleviate  it  fully.  Although  some  research 
(Hamen  and  Nihtila  1995]  indicates  that  the  use  of  electronic  communication  reduces  the  effect 
of  physical  distance  on  communication  activities,  face  to  face  communication  is  still  necessary. 

The  use  of  information  technologies  can  be  enhanced  if  they  are  seen  as  a  tool  to  facilitate  the 
business  and  integrated  into  the  business.  Davidow  and  Malone  [1992]  recognize  that,  "in  years 
to  come,  incremental  differences  in  companies'  abilit''?s  to  acquire,  distribute,  store,  analyze,  and 
invoke  actions  based  on  information  will  determine  the  winners  and  losers  in  the  battle  for 
customers."  Goldman  [1995]  affirms  this  research  by  mdicating  that,  "sharing  the  expense  of 
precompetiti\'e  technology,  facilities,  and  resources  leaves  more  resources  to  spend  on 
customizing  prcxluct  features  and  services  that  provide  for  competitive  ad\antage.  The  goal  is  to 
unite  complementary  core  competencies  in  order  to  serve  customers  whom  the  separate 
companies  could  not  serve  on  their  own.  Each  member  of  this  type  of  \  iilual  organi/ation  is 
chosen  because  it  brings  somethmg  unique  that  is  needed  to  meet  a  customer  opptirtunity." 
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In  theory,  the  virtual  organization  can  give  a  company  access  to  more  specialized  competencies 
than  any  one  organization  can  afford  to  maintain  and  hence  concurrently  engineer  many  more 
products.  However,  more  compelling  studies  about  the  effectiveness  of  virtual  co-location  in 
isolation  have  yet  to  be  completed. 

In  our  study,  one  of  the  vehicle  programs  utilized  resources  from  North  America  as  well  as 
Europe.  The  satellite  organization  did  not  always  have  access  to  all  of  the  resources  of  the  home 
organization  to  complete  their  projects.  If  this  is  the  case,  the  situation  is  easily  rectified  if  the 
home  organization  can  insure  that  its  satellite  organizations  are  assigned  mdependently 
executable  projects.  However,  there  must  be  adequate  information  flow  between  the  parent 
organization  and  the  satellite  in  order  to  utilize  each  organization's  resources  effectively. 

Lastly,  co-location  should  not  be  considered  the  complete  solution  to  this  problem.  Tyre  and  von 
Hippel  [1995]  suggest  that  the  location  itself  plays  an  integral  role  in  a  project  team's  efficacy. 
They  believe  that  managers  should  consider  what  types  of  knowledge  and  what  forms  of  search 
are  most  important  to  a  team's  progress  at  any  given  time,  and  select  the  work  location 
accordingly. 

Importance  of  effective  communication 

Automotive  audio  systems  have  traditionally  been  designed  by  largely  autonomous  organizations 
either  within  automobile  manufacturing  firms  or  at  supplier  firms.  Sometimes  this  type  of 
organizational  structure  promotes  the  visual  style  of  an  audio  system  interface  to  be  very 
different  from  the  style  of  the  vehicle  itself.    Recognizing  this  problem,  the  US  auto  industry  has 
placed  greater  emphasis  on  organizing  vehicle  line  teams.  In  this  fashion,  they  hope  to  create 
natural  communication  patterns  between  subsystem  designers  (e.g.,  audio  systems)  and  the 
vehicle  interior  designers. 
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Organi7ati(>ns  lend  lo  (Jc\  clop  languages  ol  ihcir  own  as  people  a  ho  share  a  common  set  of 
problems  lend  lo  share  shorihand  ways  ol  relemng  loactiviiies  and  technologies.  Technical 
dcparlmcnls  hire  people  who  have  been  irained  and  know  ihe  language  of  Ihc  deparlmcnl's 
specially.  Such  a  language  pcrmils  people  lo  communicalc  more  efficiently  by  transmitting 
more  information  with  fewer  symbols.  However,  despite  the  fact  that  specialized  languages 
increase  efficiency  within  a  department,  they  decrease  efficiency  between  organizations 
[Galbraith  1973]. 

Many  of  the  interactions  we  studied  involved  these  types  of  formal  organizational  ties. 
However,  we  did  observe  thai  much  of  the  necessary  technical  communication  occurred  through 
the  informal  organizational  networks.  Krackhardt  and  Hanson  1 1993]  indicate  that  although 
these  informal  networks  can  expedite  delayed  initiatives  and  aid  in  meeting  difficult  deadlines, 
they  can  also  bl(x;k  communication  and  evoke  opp<isilion  unless  managers  know  how  lo  identify 
and  direct  them.  Moreover,  Granovetter's  [1973]  research  has  shown  that  small-scale 
interactions  can  be  translated  into  large-scale  patterns,  that  is  the  strength  of  mtcrpersonal  ties 
can  affect  the  political  makeup  of  the  organization. 

The  underlying  philosophies  of  an  international  corporation  often  assume  global  ease  of 

communication. 

Architectural  direction  can  be  very  difficult  to  communicate  across  organizations.  For  example, 

even  the  simplest  explanations  of  architectural  characteristics  can  be  misinterpreted  if  a  group 

speaking  American  English  conveys  the  message  to  a  group  speaking  British  English  or  a  group 

speaking  English  translated  from  German. 

In  the  company  that  we  studied,  the  European  di\ision  and  the  North  American  di\ision  shared 
only  human  capital  until  recently,  now  they  also  share  products.  Only  now  is  this  compan\ 
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experiencing  the  growing  pains  of  globalization  as  heightened  by  the  differences  in  each 
organization's  decision  models  and  understandings  of  organizational  processes. 

As  Allison  [1971]  showed  through  his  analysis  of  the  Cuban  missile  crisis,  the  acts  of  complex 
organizations  cannot  be  simply  understood  by  analogy  as  the  purposive  acts  of  individuals.  This 
simplification  obscures  the  neglected  fact  that  corporate  policy  decisions  are  not  made  by  one 
decisionmaker,  but  rather  by  the  bureaucratic  results  of  a  conglomerate  of  large  internal 
organizations. 

Social  research  has  shown  that  the  creation  of  lateral  relations  in  an  organization  often  provides  a 
mechanism  which  reduces  the  quantity  of  decisions  referred  upward  in  the  corporate  hierarchy. 
It  is  assumed  that  informal  processes  are  necessary  and  inevitable  in  a  complex  organization. 
However,  when  a  large  product  development  team  is  comprised  of  differing  attitudes,  contains 
members  from  different  countries  and  is  geographically  dispersed,  the  effective  use  of  joint 
decision  making  may  also  require  a  formally  designed  process  [Galbraith  1973]. 

Identification  of  internally  efficient  departments  which  are  hindered  by  barriers  to  external 
communication  may  allow  an  organization  to  select  a  product  architecture  such  that  the  high- 
frequency  interactions  occur  inside  departments  rather  than  across  departments. 

Effects  of  organizational  culture  on  architecture. 

Organizations  as  a  whole  show  patterns  of  basic  assumptions  that  are  invented,  discovered,  or 
developed  by  given  groups  as  they  learn  to  cope  with  their  specific  problems.  These  problems 
include,  but  are  not  limited  to  external  adaptation  and  internal  integration  [Schein  1985].  Groups 
within  the  organization  may  also  exhibit  their  own  distinct  group  culture. 
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Wc  observed  that  the  shared  experiences,  knowledge,  and  understanding  of  the  organi/iition 
caused  each  group  lo  bring  dillcrcnl  assumptions  with  it  to  the  larger  prcxlucl  dc\ciopmcnt  team 
and  as  a  result  affected  architecture  decisions. 

In  one  example,  the  company  wanted  to  design  a  single  audio  architecture  for  global  use. 
However,  engineering  decisions  regarding  interlaces  and  connections  became  ver>'  difficult  to 
resolve.  We  later  found  that  the  European  engineers  regard  mcxiulanty  (and  upgradability)  as 
fundamental  lo  a  prcxluct's  architecture,  whereas  the  North  American  engineers  f(x;us  more  on 
specific  prcxluct  and  vehicle  line  features.  Interestingly  enough,  this  finding  reOects  not  only  a 
dilference  in  organizational  cultures,  but  appears  lo  suggest  that  this  difference  is  due  to  distinct 
differences  in  the  regional  customers.  This  difference  may  affect  the  firm's  ability  to  manage  the 
discontinuity  between  present  products  and  unknown  future  products  and  hamper  a  thorough 
understanding  of  their  markets  and  customers  [Dougherty  1987J. 

The  managerial  implications  of  understanding  a  group's  culture  include  enhancing 
management's  ability  to  utilize  tacit,  highly  situated  knowledge  of  employees  such  as  machine 
operators,  secretaries,  or  customers  [Tyre  and  von  Hippcl  1995].  Tyre  and  \on  Hippel  [1995] 
suggest  that  observing  these  kinds  of  employees  in  their  normal  work  environment  (i.e.  their  sub- 
group culture  or  shared  values)  allows  managers  to  develop  a  "contextualized  appreciation"  of 
issues  that  these  employees  may  face. 

Lastly,  Foster  [1986]  has  shown  that  technological  change  necessitates  significant  organizational 
change.  He  states  that  companies  lose  their  leadership  not  only  because  of  weak  strategies,  but 
also  because  of  strong  cultures. 
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IV.  Conclusion 

This  paper  describes  our  exploration  of  the  linkages  between  product  architecture  and 
organizational  design  by  bringing  forth  specific  examples  solidifying  the  premise  that  product 
architecture  and  organizational  design  are  not  independent.  In  fact,  they  are  interdependent  and 
affect  each  other  as  we  have  found  through  our  case  studies.  For  this  study,  we  interviewed 
members  of  audio-system  teams  in  two  very  different  organizations  of  a  large  American 
automotive  manufacturing  firm.  We  found  that  the  technical  decisions  relating  to 
decomposition,  architecture  and  integration  are  tightly  coupled  to  both  the  capabilities  and  the 
design  of  the  organization  which  must  execute  the  development  process. 

We  observed  in  our  case  studies  that  organizations  do  simultaneously  exhibit  mechanisms  of 
product  architecture  affecting  organizational  structure  as  well  as  patterns  of  organizational 
structure  affecting  product  architecture.  Hence,  we  assert  that  the  technical  architecture  of  a 
product  co-evolves  with  the  organizational  design.  The  notion  of  co-evolution  is  a  dynamic 
extension  of  Conway's  earlier  observation  that  organizations  create  technical  system  designs 
which  match  the  communications  structure  of  the  organization  itself  [Conway  1968]. 


Decomposition 


Product 
Architecture 


Organization 
Design 


Figure  8.  Problem  Relationships 

We  propose  a  possible  mechanism  which  may  help  to  explain  this  fundamental  coupling: 
architecture  and  organization  are  linked  through  the  process  of  problem  decomposition  and 
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system  intcgralion.  Dc\clopcrs  handle  complex  system  design  challenges  by  dccomposinu  the 
large  system  \n[o  simpler  (incs  which  can  then  be  designed  or  specified  for  ouLsourcing.  (This 
decomfX")sition  process  is  repealed  until  the  subsystems  are  simple  enough  to  tackle.)  At  some 
point,  the  development  organization's  challenge  is  to  mtc^ratc  the  various  pieces  together  into  a 
complete  workmg  system.  In  fact,  decomposition  and  integration  arc  generalized  inverse 
problems. 

We  are  ot"  the  opinion  that  establishing  and  following  prcx'edures  which  take  advantage  of  the 
benefits  achie\  ed  through  recognizing  the  coupling  of  these  decisions  can  facilitate  the  product 
development  process.  Inappropriate  or  inllexible  architectural  or  organizational  frameworks 
may  be  curtailed.  For  example,  if  an  organiz.ation  has  evolved  from  being  tcx)  closely  aligned  to 
a  very  modular  prtxlucl  architecture,  an  understanding  of  co-evolution  may  catalyze  a  more 
balanced  move  towards  a  more  integrated  organizational  structure.  Perhaps  a  more  effective 
malnx  structure  can  be  formed. 

Over  time  the  product  architecture  will  change  at  a  different  rate  than  the  design  of  the 
organ iziiti on.  Even  though  these  changes  happen  slowly,  it  is  essential  to  acknowledge  the 
coupling  at  the  decision  level  in  order  to  achieve  the  benefits  of  recognizing  their 
interdependence.  It  does  not  appear  feasible  for  new  generations  of  architectural  changes  to  far 
exceed  that  of  the  pace  of  organizational  rc-slructurng. 

While  we  were  able  to  make  string  observations  based  on  our  field  study,  many  of  our 
conclusions  arc  merely  speculative  since  this  study  represents  only  a  single  class  of  prcxluct 
design.  In  order  to  strengthen  the  conclusions  that  might  be  drawn,  it  would  be  useful  to  conduct 
studies  of  several  different  prtxlucts  to  confirm  the  robustness  of  our  findings.  Additionally,  an 
exploration  of  the  following  research  questions  might  al.so  be  infomiativc:   How  can  the  time 
constants  for  organizational  change  and  for  architectural  change  be  measured?  When  is  the  time 


constant  for  the  organizational  change  smaller  than  the  time  constant  for  architectural  change? 
What  attributes  of  product  plans  and  organizational  design  plans  lend  themselves  to  enhancing 
strategic  planning?  What  types  of  organizations  can  more  easily  adopt  new  product 
architectures?  Is  an  organization  where  the  major  skills  and  capabilities  of  the  people  set  the 
parameters  of  the  product  architectures  more  successful  than  one  in  which  the  product 
architectures  dictate  the  organizational  structure?  Can  requirements  for  high-frequency  and  low- 
frequency  communications  be  identified  by  a  priori  knowledge  of  interface  specifications?  To 
what  extent  do  collaboration  technologies  change  the  nature  of  technical  interactions  in  product 
development? 
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